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H ere's a technical question for you— do you 
ever use become: in your applications? What 
twigged the issue was the fact that, for a long 
time now, our training materials have includ¬ 
ed an application that makes use of the become: op¬ 
eration. It was written to illustrate the power of 
Smal Ital k and to i ntroduce people to the i ssue of object 
mutation. But we know that i n our own software devel¬ 
opment, we rarely use it; we’re sure that’s true of others 
as well. The question is, why not? And if it’s not to be 
used, then should vendors con- 
tinueto support it? 

For those of you who may not 
befamiliar with become:, it is de- , i / tprh 
fined as an instance method in 
the class Object. The intention of for yOU — C/( 

the message send "objectl be- " 

come: object2” is to mutate objectl DSCOITH 

into object2. However, there are anrtli 

two different implementations 
found in the various Smalltalks. 

Visual Smalltalk's implementa¬ 
tion has always had the effect that 
all references to objectl are made references to object2; 
objectl is left with no references and is therefore gar¬ 
bage collected. IBM Smalltalk for Windows and OS/2 
provide similar behavior. VisualWorks, on the other 
hand, implements a become: that swaps the references 
between the two objects—all theoriginal references to 
objectl become references to object2, and all theorigi¬ 
nal references to object2 are made references toobjectl; 
neither object gets garbage collected. 

This, of course, leaves you with radically different 
behavior for the same message, which is one obvious 
reason for not using become:. The classic example of 
this problem issomeObject become: nil yields radically 
different results! Another reason for the lack of use 
of become: is historical. Early implementations of 
Smalltalk did not always yield the expected results 
and/or perform well at all. As a result, many gave up 
on theoperation and found another approach. 

Butthequestion still lingers—even ifthe issues list¬ 
ed were resolved, would it be appropriate to make use 
of become:? The answer, of course, is "it depends...". 
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The real issue is there are two different interpretations 
of what become: really means in an application. A 
statement such as "with become:, you can make an 
elephant become a mouse” is not appropriate be¬ 
cause the two objects are not related to each other i n 
any manner. This really represents replacement, not 
mutation. 

Another interpretation of become: isthat it provides 
a mechanism to allow an object to dynamically 
change its behavior. Consider this statement: "As a 
boy grows older, he becomes a 
man.” The message become: can 
be used in this context to model 
.cx-4-inr, the changing behavior of a per- 

cai question son For examp | e mob iiit y is 

OU ever USe achieved by a young child 
through crawling; an older child 
n your walks. As a result, when the mes- 

h j nn <-? sage move Around is sent to a 

* f ! person, the message is inter¬ 

preted differently at different 
ages. A possible implementation 
would be to have a child object 
actually mutate into an adult object. It is important 
that the object decides to do this itself and does not 
depend on other objects. Thisavoidscodelikeself age 
<2 ifTrue: [self crawl] if False: [self walk]. Although the 
example is trivial, it is illustrative of the type of behav¬ 
ior changes we require from an object. 

So, is become: necessary? Probably. Applications do 
exist where it would be beneficial and perhaps even 
appropriate. But in the end we find it is a neat idea, 
but for most problems we should find another solu¬ 
tion. For example, in the person examplecited, it's al¬ 
ways possible to introduce a generic Person object and 
have them have roles or characteristics So, a person 
may either have child or adult characteristics and its 
behavior is directly dependent on which characteris¬ 
tics it has. These are nontrivial systems to implement, 
but they give you thedesired behavior. 

As this is the Smalltalk Solutions issue, we hope 
many of you take advantage of the conference. It's the 
best opportunity for Smalltalkto show off its success¬ 
es. Please drop by and introduce yourself! 


2 


http://www.sigs.com 


The Smalltalk Report 







